Deployment policies ที่ใช้ได้ใน AWS Elastic Beanstalk มีอะไรบ้าง

นี่เป็นบทความแปล ที่มีเนื้อหามาจากบทความภาษาญี่ปุ่นของ Classmethod, Inc. ในหัวข้อ「AWS Elastic Beanstalkで使えるデプロイポリシーを理解する」 หากผู้อ่านสนใจอ่านเนื้อหาต้นฉบับสามารถอ่านได้ที่ลิ้งค์ "บทความต้นฉบับ" ด้านล่าง เนื้อหาในบทความนี้การอธิบายบางอย่างจะถูกปรับให้เข้าใจง่ายขึ้นทำให้แตกต่างจากต้นฉบับในบางจุด

#Classmethod Thailand

#Thai Language

#AWS

#AWS-Thai

#AWS Elastic Beanstalk

Supanut Akaram

2022.08.03

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

ต้า จาก Technical Support Team ครับ

ครั้งนี้เราจะมาคุยทำความเข้าใจเกี่ยวกับ Deployment policies ที่ใช้ในการ Deploy แอปพลิเคชันเวอร์ชันใหม่ใน AWS Elastic Beanstalk กันครับ

Deployment policies

Deployment policies ที่ใช้ได้ใน AWS Elastic Beanstalk แบ่งออกใหญ่ๆได้เป็น 4 policy ครับ

All at Once
Rolling
Rolling with additional batch
Immutable

All at Once

All at Once คือ Policy ที่จะ Deploy ไปยังแอปพลิเคชันที่มีอยู่แล้วทั้งหมด พร้อมๆกัน

โดยตามภาพที่เห็น เราจะกำหนดว่ามีแอปพลิเคชั่น version 1 รันอยู่บน Instance 4 ตัว
แล้วเราต้องการอัพเดทพวกมันเป็น แอปพลิเคชั่น version 2

พื้นหลังสีฟ้าในภาพด้านล่างหมายความว่า หยุดการให้บริการและอยู่ในสภาพใช้งานไม่ได้

ถ้าเรา Deploy แอปพลิเคชัน version 2 ด้วย All at Once Policy
Instance ทุกตัวจะทำการ Deploy ทันที ตามภาพที่เห็นด้านบน ทำให้ระหว่างที่ทำการ Deploy แต่ละ Instance จะหยุดการให้บริการและอยู่ในสภาพใช้งานไม่ได้

หลังจาก Deploy เสร็จแล้ว เราจะสามารถเปิดใช้งานทุกๆ Instance ด้วย แอปพลิเคชัน version 2 ได้ครับ
All at Once Policy จะทำให้เกิด Downtime ระยะสั้นขึ้น แต่ก็เป็น Deployment policies ที่ใช้งานง่ายที่สุด และ เร็วที่สุดครับ

Rolling

Rolling คือ Policy ที่จะ Deploy เวอร์ชั่นใหม่ไปยัง batch ครับ

เราจำเป็นต้องตั้งค่า Batch size ตอนที่ Delploy โดยใช้ Rolling policy โดยในการทดลองครั้งนี้เราจะกำหนด Batch size อยู่ที่ 50 % แล้วทำการ Deploy แอปพลิเคชัน version 2 ครับ

Instance จำนวน 2 จาก 4 ตัว ถูกทำการ DEploy เนื่องจาก เราตั้งค่า Batch size อยู่ที่ 50%
ในระหว่าง 2 ตัวที่ทำการ Deploy จะหยุดการให้บริการและอยู่ในสภาพใช้งานไม่ได้ และจะลด capacity ตามจำนวน Batch size(ลดลง 50%)

หลังจาก Instance ทั้ง 2 ตัว ทำการ Deploy เสร็จ ทั้ง 2 ตัวนั้นจะกลายเป็นแอปพลิเคชัน version 2 โดยในตอนนี้เราจะมีทั้ง version 1, 2(เก่าและใหม่) เปิดใช้งานอยู่ ทำให้อาจจะเกิดโอกาสที่ User จะเข้าใช้งาน version ที่แตกต่างกันได้

หลังจากนั้น จะทำการ Deploy Instance 2 ตัวที่เหลือ โดยในระหว่าง 2 ตัวที่ทำการ Deploy จะหยุดการให้บริการและอยู่ในสภาพใช้งานไม่ได้ และจะลด capacity ตามจำนวน Batch size(ลดลง 50%)

หลังจาก Deploy เสร็จแล้ว จะเป็นการเปิดใช้งานทุกๆ Instance ด้วย แอปพลิเคชัน version 2 ครับ
เมื่อเปรียบเทียบ Rolling Policy กับ All at once Policy แล้ว Rolling Policy จะเสีียในเรื่องที่มี capacity ลดลง แต่จะไม่เกิด Downtime แบบสมบูรณ์แบบ(เกิดที่ละขั้นตามที่เราตั้งค่า) แต่ก็อาจจะเจอปัญหาในเรื่องที่มีช่วงเวลาที่ เวอร์ชั่นใหม่ กับ เก่า ปนกันอยู่

Rolling with additional batch

Rolling with additional batch คือ Policy ที่จะ Deploy เวอร์ชั่นใหม่ไปยัง batch เหมือนกับ Rolling ครับ แต่ในขณะ Deploy จะทำการเพิ่ม Instance ให้ capacity สามารถคงอยู่ได้ 100% ครับ

เราจะตั้งค่า Batch size อยู่ที่ 50% เหมือนกับ Rolling Policy

Rolling with additional batch policy จะทำการสร้าง Instance ใหม่ เท่ากับ Batch size แล้วทำการ Deploy
ถ้าเป็น Rolling Policy Capacity จะลดลง แต่ถ้าเป็น Rolling with additional batch policy เราจะทำการ Deploy Instance ใหม่ที่สร้างขึ้น ซึ่งไม่ได้ทำการเชื่อมต่อแต่เดิมอยุ๋แล้ว ทำให้ สามารถคง Capacity ไว้ที่ 100% เหมือนเดิมได้

หลังจาก Deploy Instance ใหม่ เสร็จแล้ว จะถูกนำไปเชื่อมต่อกับ Load Balancer ครับ
ในระหว่างนี้ ก็จะมีเวอร์ชั่นใหม่กับเก่าปนกันอยู่ เหมือนกับ Rolling ครับ

หลังจากนั้น ก็จะทำการถอดการเชื่อมต่อ Instance จาก Load Balancer เท่ากับ Batch size ในระหว่างนี้ก็จะยังเหลือ Instance 4 ตัวทำงานอยู่ ทำให้สามารถคง Capacity ไว้ที่ 100% เหมือนเดิมได้

หลังจาก Deploy เราก็จะได้ แอปพลิเคชั่น version 2 ทำงานอยู่ใน 4 Instance

หลังจากนั้น เราก็จะทำการ Terminate Instance 2 ตัวที่ทำงานอยู่ใน version 1

Rolling with additional batch มีข้อแตกต่างจาก Rolling อยู่ที่ในขณะ Deploy นั้นจะสามารถคง Capacity ให้อยู่ที่ 100% ได้ ทำให้มันมักถูกเลือกในการใช้งานจริง แต่ยังคงเหลือปัญหาในเรื่องที่มีช่วงเวลาที่ เวอร์ชั่นใหม่ กับ เก่า ปนกันอยู่

Immutable

Immutable คือ Policy ที่จะ Deploy โดยไม่ทำการเปลี่ยนแปลง Instance ที่ใช้อยู่ครับ

โดยเราจะทำการกำหนดว่าต้องการที่จะอัพเดท แอปพลิเคชันจาก version 1 ไป version 2 เหมือนที่เคยทำมาครับ

Immutable policy จะทำการสร้าง Auto Scaling Group ใหม่ ตามภาพที่เห็น หลังจากนั้นจะทำการ Run Instance แล้วทำการ Deploy ครับ

หลังจาก Deploy เสร็จแล้วจะทำการเชื่อมต่อ Load Balancer เพื่อตรวจสอบว่าสามารถใช้งานได้จริงหรือเปล่า

หลังจากตรวจสอบได้ว่าทำงานได้แล้ว จะทำการสร้าง Instance ใหม่ 3 ตัว ใน Auto Scaling Group ใหม่ แล้วทำการ Deploy ครับ

หลังจาก Deploy เสร็จแล้วจะทำการเชื่อมต่อ Load Balancer ในตอนนี้นี้เราจะมีกลุ่มที่แบ่งเป็นแอปพลิเคชัน version 1 และ 2 ทำงานอยู่ครับ

สุดท้ายแล้วเราจะทำการ Terminate Instance ที่อยู่ในกลุ่ม version 1 ออกครับ

Immutable Policy จะ Deploy โดยไม่ทำการเปลี่ยนแปลง Instance ที่ใช้อยู่ครับ
แต่ทว่าจะมีช่วงเวลาที่ เวอร์ชั่นใหม่ กับ เก่า ปนกันอยู่เหมือนเดิมครับ

Environment แบบนี้มี Policy แบบไหนให้เลือก

Environment	Policy ที่เลือกได้
Instance ตัวเดียว	All at Once
Instance ตัวเดียว	Immutable
Load Balancer, Auto Scaling Group	All at Once
	Rolling
	Rolling with additional batch
	Immutable

Blue/Green(เพิ่มเติม)

ในหัวข้อที่แล้วๆ เราได้ทำความรู้จักเกี่ยวกับ Deployment policies ที่มักจะถูกใช้ใน AWS Elastic Beanstalk กันไปแล้ว แต่ไม่ว่าจะเป็น All at Once Policy, Rolling Policy, Rolling with additional batch Policy, หรือ Immutable Policy ก็จะมีปัญหาเดียวกันอยู่

มีช่วงเวลาที่เวอร์ชั่นใหม่ กับ เก่า ปนกันอยู่ในเวลาเดียวกัน

หากเราไม่ต้องการให้เวอร์ชั่นที่ต่างกันปนกันอยู๋ในเวลาเดียวกัน เราสามารถใช้ Blue/Green Deploy ในการแก้ไขปัญหานี้ได้

Blue/Green Deploy

ครั้งนี้เราจะทำการ version update ด้วย Blue/Green Deploy กับ แอปพลิเคชั่นที่ทำงานอยู่ใน Environment เดิมเหมือนกับที่ผ่านมา

ก่อนอื่น เราจะต้องสร้าง Clone ตัว Environment ที่เราใช้อยู่ ใน 2 Environment นี้มีจุดแตกต่างกันแค่ ชื่อ DNS ครับ

หลังจากนั้นเราก็จะทำการ Deploy Clone ที่สร้างขึ้นมาครับ ในตอนนี้แนะนำให้ใช้ All at Once Deploy เพราะเราไม่ได้ใช้อยู่ จะเกิด Downtime ขึ้นก็ไม่มีปัญหาอะไรครับ

หลังจาก Deploy เสร็จ เราตรวจว่าแอปลิเคชันใช้งานได้ตามปกติแล้ว เราจะทำการเปลี่ยน DNS จาก Environment ที่ใช้อยู่ให้เป็น DNS ของ Clone ครับ
จากการทำเช่นนี้ จะทำให้ไม่เกิดช่วงเวลาที่มีช่วงเวลาที่เวอร์ชั่นใหม่ กับ เก่า ปนกันอยู่ครับ

ข้อแตกต่างระหว่าง Blue/Green Deploy กับ Immutable Policy

หลายคนอาจจะสงสัยว่า Blue/Green Deploy กับ Immutable Policy มันต่างกันตรงไหน ผมจึงขออธิบายในช่วงนี้ครับ

ก่อนอื่น Blue/Green Deploy จะทำการสร้าง Environment ใหม่ หรือ Clone จาก Environment ที่มีอยู่ แล้วทำการ Deploy ทำให้ชื่อ DNS ระหว่าง Environment ที่มีอยู่ กับ Environment ใหม่ แตกต่างกัน
แต่ว่า Immutable Policy จะไม่ได้ทำการสร้าง Environment ใหม่ แต่จะเป็นการเพิ่ม Auto Scaling Group เข้าไปใน Environment เดียวกันครับ ทำให้ Auto Scaling Group 2 ตัวมีชื่อ DNS ที่เหมือนกันครับ

แถมท้าย

ในบทความนี้เราคุยกันเกี่ยวกับเรื่อง Deploy Policy ที่ใช้ได้ใน AWS Elastic Beanstalk กับ Blue/Green Deploy กันไปแล้ว

Deployment policies แบบนี้ พอเราจำได้แล้ว แต่พอเวลาผ่านไปก็อาจจะลืมกันไปได้บ้างครับ ซึ่งผมก็หวังว่าบทความนี้จะเป็นประโยชน์ต่อท่านผู้อ่านที่ลืมเกี่ยวกับ Deployment policies แล้วอยากกลับมาทบทวนใหม่ครับ
แล้วเจอกันในบทความต่อไป สวัสดีครับ / ต้า